Systems and Methods For Efficient Handling of Data Traffic and Processing Within a Processing Device

ABSTRACT

The present invention provides an improved platform hub that aims to, in some embodiments, optimize system resources to improve system performance and/or reduce consumption of power.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.13/474,932, filed on May 18, 2012 (published as U.S. 2013-0016729),which is a continuation of U.S. application Ser. No. 12/875,343, filedSep. 3, 2010 (now U.S. Pat. No. 8,209,457), which is a continuation ofU.S. application Ser. No. 11/776,285, filed Jul. 11, 2007 (now U.S. Pat.No. 7,793,032). The above identified applications and publications areincorporated by reference.

BACKGROUND

1. Field of the Invention

The present invention relates generally to processing devices, and, morespecifically to systems and methods for improving the handling of themovement of data and processing of data within a processing device.

2. Discussion of the Background

FIG. 1 illustrates a conventional processing device 100. Processingdevice 100 includes a housing 102 that houses one or more agents 110 anda platform hub 120. For example, housing 102 may house the followingagents: zero or more acceleration agents 110 a(1)-110 a(N), zero or moreprocessing agents 110 b(1)-110 b(N), zero or more communication agents110 c(1)-110 c(N), zero or more storage agents 110 d, zero or morelegacy agents 110 e, zero or more external memory agents 110 f, etc. Acommunication agent 110 c may include a physical connection to acommunication channel (e.g., a fiber cable or Ethernet cable). Theplatform hub 120 is sometimes referred to as a “south bridge (SB)” or“north bridge (NB).” A processing agent 110 b may be an x86microprocessor from Intel, or may be processing device sold by AMD orother source of processing devices, and the platform hub 120 may becontained in a chip that sits on the same circuit board as a processingagent 110 b.

FIG. 2A illustrates one example processing agent 110 b. As shown in FIG.2, a processing agent 110 b may include (a) a host 202 that includes oneor more central processing units (CPU) and (2) one or more memory bankscoupled to host 202. In the example shown, there are two memory banks,one that is positioned to right of the host 202 and one that ispositioned to the left of the host 202. FIG. 2B attempts to illustrateanother example processing agent 110 b. As illustrated in FIG. 2B, aprocessing agent 110 b can also be a multi-processor cluster (e.g. AMDOpteron™ x86 System). In such a case, the platform hub can be connectedto one or a subset of processors in the cluster through a SB/NB Link,but can, in most cases, interact with all of the processors or memoriesin the cluster since the cluster is interconnected.

Platform Hub 120 is configured to enable the agents 110 to communicatewith a processing agent 110 b, but is not configured to enable the“non-processing agents” (e.g., agents 110 a,c,d,e,f) to communicatedirectly with each other, but this is not the only disadvantage ofplatform hub 120.

Thus, in the conventional processing device 100, all data must flowthrough a processing agent 110 b. That is, for example, if data outputfrom a communication agent 110 c is ultimately destined for a storageagent 110 d, the data output from communication agent 110 c is receivedby platform hub 120, which then provides the data to a processing agent110 b such that the data is stored in a memory unit of the processingagent. After the data is stored in the memory unit, the data is thenreceived from the memory unit and provided to platform hub 120, whichthen provides the data to storage agent 110 d. Each data movementtransaction consumes system resources due to the data handling andconsumes system power due to the data passing process.

Some embodiments of the present invention aim to improve the datahandling and/or passing process so as to reduce the amount of systemresources and/or power that is consumed.

SUMMARY

In one aspect, the invention provides a processing device. In oneembodiment, the processing device includes: a housing; a platform hubhoused in the housing; and an agent housed in the housing and connectedto the platform hub, wherein the platform hub comprises: aninterconnect; and a classification adapter unit, wherein theclassification adapter unit is connected between the agent and theinterconnect, and the classification adapter unit is configured tointerface with the agent such that the classification adapter unit mayobtain data from the agent and may provide data to the agent. The datamay be a protocol packet (e.g., a TCP/IP packet).

In another aspect, the invention provides a chip for use in a processingdevice. In one embodiment, the chip includes: an interconnect; a firstclassification adapter unit circuit directly connected to theinterconnect; and a second classification adapter unit circuit directlyconnected to the interconnect, wherein the interconnect is configured to(a) enable the first classification adapter unit circuit to send data toand receive data from the second classification adapter unit circuit and(b) enable the second classification adapter unit circuit to send datato and receive data from the first classification adapter unit circuit,and the first classification adapter unit circuit is operable to: (1)receive a block of data from an agent, (2) add a directive to at least aportion of the data block, thereby creating a data container, and (3)transmit the data container to the second classification adapter unitcircuit by providing the data container to the interconnect.

In another aspect, the invention provides a method. In one embodiment,the method includes: receiving, at a first classification adapter unit,a data block from an agent; creating a directive in response toreceiving the data block; adding the directive to the data block,thereby creating a data container comprising the directive and the blockof data; providing, from the first classification adapter unit and to aninterconnect, the data container created by the first classificationadapter unit; receiving the data container at the interconnect, whereinthe interconnect provides the data container to a second classificationadapter unit; and receiving the data container at the secondclassification adapter unit, wherein the second classification adapterunit performs an action based, at least in part, on information includedin the data container, and the first classification adapter unit, thesecond classification adapter unit, and the interconnect are built upona chip and the chip is directly connected to a circuit board.

In some embodiments, the data block is a protocol packet and the step ofcreating the directive comprises: examining the protocol packet andcreating the directive based, at least in part, on information containedin the protocol packet. The step of examining the protocol packet mayinclude (a) examining a header portion of the protocol packet and/or (b)performing a deep packet inspection (i.e., analyzing the payload of thepacket in addition to or instead of the header of the packet) (e.g.,searching for a pattern or for certain data inside the packet payload).

The above and other embodiments of the present invention are describedbelow with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and form partof the specification, illustrate various embodiments of the presentinvention. In the drawings, like reference numbers indicate identical orfunctionally similar elements.

FIG. 1. illustrates a conventional processing device.

FIG. 2A illustrates a conventional processing agent.

FIG. 2B illustrates another conventional processing agent.

FIG. 3 illustrates a platform hub according to some embodiments of theinvention.

FIG. 4A illustrates an example data container.

FIG. 4B illustrates an example protocol packet.

FIG. 5A illustrates an example instruction structure.

FIG. 5B illustrates two way in which an instruction may be accessed.

FIG. 6 is a functional block diagram of a classification adapter unitaccording to one embodiment.

FIG. 7 illustrates an example data flow.

FIG. 8 is a flow chart illustrating a process according to an embodimentof the invention.

FIG. 9 illustrates an example data container.

FIG. 10 illustrates an example data flow.

FIG. 11 is a flow chart illustrating a process according to anembodiment of the invention.

FIG. 12 illustrates an example data flow.

FIG. 13 is a flow chart illustrating a process according to anembodiment of the invention.

FIG. 14 illustrates an example directive.

FIG. 15 illustrates an example data flow.

FIG. 16 is a flow chart illustrating a process according to anembodiment of the invention.

FIG. 17 illustrates an example data flow.

FIG. 18 is a flow chart illustrating a process according to anembodiment of the invention.

FIG. 19 illustrates an example directive.

FIGS. 20A,B illustrate an example data flow.

FIGS. 21A,B is a flow chart illustrating a process according to anembodiment of the invention.

FIG. 22 illustrates an example classification adapter unit.

FIGS. 23-26 illustrate various other embodiments of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

As used herein, the words “a” and “an” mean “one or more.”

In one embodiment, the present invention provides an improved platformhub 320, which may be contained in a chip, and which chip may beattached to the same circuit board as a processing agent 110 b.

Platform hub 320, in contrast to conventional platform hub 102, may, insome embodiments, be configured to, among other things, enable thenon-processing agents to communicate with each other without having toinvolve a processing agent. Other features that may be implemented byplatform hub 320 are described below. Platform hub 320 may replace anexisting platform hub 120 or may be used in conjunction with an existingplatform hub 120.

As illustrated in FIG. 3, platform hub 320 may include one or moreclassification adapter units 310 (or “adapters” for short) coupled to aninterconnect 330 for receiving data from and transmitting data to aclassification adapter unit 310. Interconnect 330 may include a router,a switching circuit (e.g., a crossbar switch or other switchingcircuit), etc.

In the illustrated embodiment, each classification adapter unit 310 isconnected between an agent 110 and interconnect 330. Each adapter 310may be configured to be able to obtain data directly from the agent 110to which it is coupled. This data is referred to as a “data payload.”This data payload may be a protocol packet (e.g., a TCP packet), a blockof information that was created by the agent in order to encapsulate atransaction of some sort, or some other block of data. As illustrated,some agents may be included within hub 320, while others exist outsideof hub 320. Additionally, an agent may be included in an adapter unit310. For example, an agent, such as a central processing unit, my beincluded in an adapter unit 310.

In some embodiments, an adapter 310 may be configured to (a) obtain froman agent 110 a data payload (e.g., a block of data) (b) examine at leastsome of the data contained in the data payload and (c) take an actionbased on the examined data. The action taken may include one or more ofthe following: (1) communicating information to another adapter 310, (2)communicating information to a processing agent 110 b, (3) modifying thedata payload, (4) discarding the data payload, etc.

For example, in some embodiments, a communication adapter (i.e., anadapter 310 connected to a communication agent 110 c) may be configuredto (a) receive from a communication agent a data payload (e.g., aprotocol packet such as a TCP/IP packet), (b) examine a header containedin the data payload (e.g., a TCP/IP header), and (c) take some action(e.g., drop the TCP/IP packet) based on information contained in theheader of the packet and/or information configured in the adapter 310(e.g., a list of known viruses, a list of the last 50 flows that exitedin the system).

In some embodiments, one adapter 310 may have a different structure andmay perform different functions from another adapter 310. For example, aclassification adapter 31 that is coupled to an acceleration agent 110 amay have different functionality and/or a different structure than aclassification adapter 310 that is connected to a processing agent 110b. As another example, a classification adapter 310 that is coupled to acommunication agent 110 c(1) may have different functionality and/or adifferent structure than a classification adapter 310 that is coupled toa communication agent 110 c(2).

More specifically, in some embodiments, an adapter 310 may be speciallydesigned to match the nature of the agent to which it is connected. Thismakes the physical design of each of the adapters 310 optimal for thework that needs to be done on data payloads coming from that agent. Forexample, an adapter serving communication agent 110 c(1) may bespecially designed to match the nature of the port to which it isconnected through agent 110 c(1). Accordingly, the design of such anadapter may be optimized for the types of protocol packets that arereceived by the port to which it is coupled. The distribution to small,different, dedicated adapter enables a hardware implementation that cansatisfy the full bandwidth of the port.

In some embodiments, each adapter 310 may implement a directive drivenarchitecture. For example, each adapter 310 may be configured such thatit is able to add a “directive” to a data payload received from an agent110, thereby creating a data container. Thus, this new data structure(the data container) contains information (i.e., the directive) “glued”to the data payload, preferably, at an accessible place (e.g., at thehead or tail of the data payload). The encapsulation of a directivein—band with a data payload may allow for efficient use of resourcesvia, for example, effective routing, delivering statistic platforminformation, and actions to be taken on the data payload.

The directive may include any combination of the following: routinginformation, quality of service information, vlan-tag insertioncommands, information characterizing the data payload (e.g., “this datapayload is a media container”), path related information (e.g.,information regarding the path the data payload traversed), platforminformation (e.g., congestion, device status), etc.

Thus, the data payload-directive coupling gives the ability to passcontrol information in-band with the data payload, instead of passing itout-of-band in a different control path. The in-band control passingmethod enables the platform hub 320 to be scalable and be able to linkother platform hubs 320.

The directive added to a data payload by an adapter 310, can be used byinterconnect 330 to, among other things, determine the adapter to whichthe data container should be directed.

The directive can also be used by the adapter 310 that receives the datacontainer from the interconnect 330. For example, the adapter 310 thatreceives the data container from interconnect 330 can examine thedirective to determine whether an action should be performed. Thisadapter, based on the directive, may take any combination of thefollowing actions: a quality of service action, a routing action, modifythe data in the data payload, add a CRC to the data container, addvirtual LAN tags to the data, decrypt the data payload, collect/gatherfurther platform statistics (e.g., congestion information, usagestatistics) to be used by other objects, etc.

FIG. 4A illustrates a data container 400 according to some embodimentsof the invention. As shown in FIG. 4A, data container 400 includes adata payload 402 that was produced by an agent 110 and a directive 404that was added to the payload 402 by the adapter 310 connected to theagent 110, which adapter 310 received the payload 402 from the agent110. In the example shown in FIG. 4A the directive 404 is attached tothe head of the data payload 402, but it may also be attached at otherlocations, such as the tail.

The directive 404 may be a simple bit vector. But, in some embodiments,it is a program-oriented structure because such a structure may be moreefficient, especially in an in-line distributed classificationarchitecture. In the embodiments in which the directive has a programoriented structure, the directive may include a set of instructions thatcan be random-accessed and/or stack-like accessed.

FIG. 4B illustrates an example data payload 402. In the example shown inFIG. 4B, data payload 400 is a protocol packet 450, which packet 450includes a packet header portion 451 and a protocol packet data payloadportion 452.

The set of instructions attached to a data payload by an adapter 310 mayform a sequence of operations to be performed on the data payload. FIG.5A illustrates one example of the structure of such functions. Asillustrated in FIG. 5A, an instruction may include three parts: (1) acommand operation code (“command Opcode”) 501; (2) operands 502; and (3)immediate information 503.

In some embodiments, the directive may include a list of instructions.The instructions in the list may be accessed randomly or stack based, asillustrated in FIG. 5B. There may be advantages to stack based access ofthe instructions. For example, each adapter 310 that receives a datacontainer can pop the top instruction in an O(1) of time. It then canperform the action required by the popped instruction. It can also usethe instruction in order to pass an instruction to an adapter through adedicated control path. When the packet returns from the adapter, theadapter can add an operation to the top of the stack by pushing it intothe directive in an O(1) amortized time. Adding an instruction to thetop of the stack enables each adapter to decide to spread its task overa set of other adapters without affecting the rest of the exaction path.The directive stack-like implementation resembles a CPU software stackin most systems. It enables performing sub-routines without harming theupper level execution flow. Random Access to the instruction set enablesout-of-order execution and insertion.

Referring now to FIG. 6, FIG. 6 illustrates a functional block diagramof an adapter according to some embodiments of the invention. Asillustrated in FIG. 6, the adapter may include two distinct data paths,a transmit (TX) data path and a receive (RX) data path.

As further illustrated, the TX data path may include an agent interface604 for interfacing the adapter 310 with an agent 110, a direct memoryaccess (DMA) engine 603, an action engine (AE) circuit 602, and aclassifier circuit 601. In the embodiment shown, classifier 601 isconnected directly between interconnect 330 and AE 602; AE 602 isconnected directly between classifier 601 and DMA 603; DMA 603 isconnected directly between AE 602 and interface 604; and interface 604is connected directly between DMA 603 and agent 110.

The RX data path includes an interface 614 for interfacing with agent110, a DMA engine 613, a classifier 612, and an AE 611. In theembodiment shown, AE 611 is connected directly between interconnect 330and classifier 601; classifier 612 is connected directly between AE 611and DMA 613; DMA 613 is connected directly between classifier 612 andinterface 614; and interface 614 is connected directly between DMA 613and agent 110.

Although a specific arrangement is shown in FIG. 6, this is forillustration and should not limit the scope of the invention as it iscontemplated that one or more of the illustrated components areoptional. For example, in some embodiments the DMA is not used.

Agent interfaces 614 and 604 may be responsible for translation betweenan agent and the platform hub. This includes handshakes between theplatform hub and the agent. For example, interface 614 may be configuredto receive data from a particular type of agent and may format the dataaccording to a predetermined format prior to providing the data to DMA613. Because each agent 110 may provide data to an interface 614 in adifferent format, each agent interface 614 is designed specifically forthe agent to which it interfaces. Accordingly, in some embodiments,agent interfaces 604 and 614 are modular such that they can be easilyreplaced. Agent interfaces 604, 614 may also encapsulate a physical linkunit that is link-dependent (i.e., PCIe, HyperTransport, etc.).

In some embodiments, DMAs 603, 613 may be responsible for addresstranslation between agents. Since some of the communication channels arenot packet based, the DMA may convert all formats to packets and back.An example of the use of the DMA module in the adapter is thetranslation of disk read and writes to blocks of data (packet like) inthe platform hub. When these packets are extracted from the platform hubthe DMA on the memory side is responsible to translate the packets backto disk transactions. In some embodiments, the use of a DMA in theadapter prevents the need for tunnels between the different agents. Whenusing the DMA, all traffic is converted to in-band traffic, forwardedthrough the platform hub and then transferred back to its originalstate. In some embodiments, DMAs, 603,613 send to and/or receive from anagent a command. For example, a DMA 603 may be operable to write data toa certain memory location and then send a command to an agent, whichcommand may cause an interrupt to occur which causes the agent to readthe data from the certain memory location. As another example, an agentmay send a command to a DMA 613 that causes the DMA to read the datastored in a predefined memory location. More specifically, for example,an acceleration agent 110 that is configured to encrypt data may send acommand to a DMA of an adapter unit 310 immediately after theacceleration agent encrypts the data and stores the data in a certainmemory, thereby causing the DMA to retrieve the encrypted data from thememory. After retrieving the encrypted data, the DMA may provide thedata to a classifier 612 for further processing as described herein.

As described above, a DMA can interact with an agent in various mannersdependant on the nature of the agent. In general there could be 3 mainlogical connections between an agent and a DMA: (1) data buffers, (2)data descriptors, and (3) control. All connections may be used bothways, and in some agents only a subset or a variation of these exist.The control path between the DMA and the agent is used to pass commands,instructions and configurations between the two. Commands from the DMAto the agent can also trigger specific sub-units inside an agent. Thisis very useful to instruct the required specific sub-unit to perform thetask at hand. Using the command path, the DMA can control not only theagent as a whole but also as a cluster of sub-units. For example, when apacket is sent to a processing agent that includes several processors,the packet may be sent to a memory of one of the processors. In suchcase, the DMA can send a control message which triggers an interrupt onthis specific processor and indicates that it has a packet waiting forit. This provides a benefit by utilizing system resources in anoptimized manner. A different example can be in an Acceleration Agent.In such a case, the DMA performs a write of a packet to the agent memoryspace using the data path. When it is finished writing the packet, itsend the agent a control message that instructs the agent to start thedesignated operation on the packet. When the agent is done, the agentwrites a control message to the DMA that the operation is finished andthe DMA reads the packet back from the acceleration agent. In most ofthe cases in which there is no (or little use) of a command path, theagent may poll a data/descriptor memory area in order to act on eachpacket.

Classifier 612 may be configured to parse the data it receives from DMA613, extract relevant fields from the data, and take an action (e.g.,create or select a command) based, at least in part, on the relevantdata fields. If classifier 612 selects or creates a command, the commandmay be passed to AE 611 and may instruct AE 611 to take a specificaction. In addition to providing commands to AE 611, classifier 612 mayalso provide to AE 611 data it received from DMA 613.

Classifier 601 may be configured to receive data containers frominterconnect 330 perform data classification based on the extraction ofinstructions included in the directive portion of a data containerreceived from interconnect 330.

A classifier 601,612 can be implemented in various manners, however, insome cases each classifier 612 may include a parser and an identifier.The parser may be configured to classify a packet (IP/TCP/UDP etc . . .) and extract relevant fields from the packet, while the identifier maycheck the fields against relevant rules. Thus, in some embodiments, aclassifier 612 may include a rules engine that implements a set of ruleson a set of fields. In some embodiments, the output of a classifier is alist of commands accompanied by extra information, if necessary, thatcould be of use by the AEs or one of the agents.

The AEs 602,611 may perform actions as directed by a classifier or asinstructed by a directive. Examples actions include: (1) adding adirective to a data payload, (2) dropping a protocol packet, (3) loadbalancing, (4) changing the payload content, etc.

In the example illustrated in FIG. 6, the classifiers 601 and 612 areshown as having the ability to directly communicate. Likewise the DMAs603 and 613 are shown as having the ability to directly communicate.However, in some embodiments, any component of adapter 310 can have theability to directly communicate with any other component of adapter 310.

Interconnect 330 enables connectivity between the different adapters. Insome embodiments, interconnect 330 is a non-blocking switch that usesthe data container as its only possible data structure. The interconnectitself is a kind of an engine as well, being capable to perform a “MOVE”instruction. Since the structure of the directive is a stacked list ofinstruction, a classifier can decide a multiple hops action. This willbe done by inserting several “MOVE” instruction one after the other.

Referring now to the RX path of adapter 310, DMA 613 may receive a datapayload from agent 110 via interface 614 and provides the data payloadto classifier 612. In response to receiving the data payload from DMA613, classifier 612 may examine the data payload and then pass to AE 611the data payload along with classification information that is used byAE 611 to create a directive to add to the data payload. Thisclassification information may be passed out-of-band to AE 611. Theclassification information may depend on the contents of the payload.For example, classifier 612 may examine one or more fields of the datapayload, and, depending on the data in those fields, select certaincommands to include in the classification information sent to AE 611.

In response to receiving from classifier 612 the data payload andclassification information, AE 611 may be configured to create adirective and add the directive to the data payload, thereby creating adata container. The directive created by AE 611 may depend on theclassification information it received from classifier 612. Aftercreating the data container, AE 611 may provide the data container tointerconnect 330, which may be configured to route the data container toan adapter 310 specified in the directive.

Referring now to the TX path of adapter 310, as discussed above,classifier 601 may receive data containers 600 from interconnect 330 andmay add and/or remove information from the container's directive 604.After classifier 601 is finished processing a received data container600, it may pass the data container 600 to AE 602. AE 602 may performsteps depending on the information contained in the data container'sdirective and/or depending on commands received from classifer 601. Forexample, AE 602 may pass the container's data payload to DMA 603. AE 620may also send out-of-band control information to DMA 603. DMA 603receives data payloads from AE 602 and provides the received datapayloads to agent 110 via interface 604.

Referring now to FIG. 22, FIG. 22 illustrates an example RX path of anadapter 310 that is connected to a processing agent 110 b. In theexample shown, we shall assume that DMA 613 obtains a packet descriptorfrom a memory unit of agent 110 b and obtains a protocol packet from amemory unit of agent 110 b, wherein the protocol packet is associatedwith the packet descriptor. The packet descriptor may contain a set offields. For example, the packet descriptor may includes the followingdata fields: packet size field that identifies the size of the protocolpacket, a destination port field that identifies a destination for theprotocol packet, a quality of service field that may identifier a packetqueue; a CPU identifier; etc.

After the DMA 613 obtains the packet descriptor and protocol packet, itmay pass the packet descriptor to a parser 2201 of classifier 612 usinga first bus 2210 and may pass the protocol packet to the parser 2201using a second bus 2211.

Parser 2201 may be configured to extract fields from the packetdescriptor and may be configured to extract fields from the header ofthe protocol packets. The Extracted fields may be provided to anidentifier 2202 and the protocol packet may be provided to the actionengine 611.

Identifier 2202 may be configured to compare a field received fromparser 2201 to configuration data to determine an action that should betaken. Based on the determined action, the identifier 2202 may send acommand to the action engine 611. Identifier 2202 may also provide tothe action engine 611 the extracted fields.

For example, if identifier 2202 determines that the destination port ofthe protocol packet is port #2, then identifier 2202 may determine thatit should send a “merge” command to the action engine 611. As discussedabove, action engine 611 may perform the action and may create a datacontainer, which is then provided to interconnect 330.

FIRST EXAMPLE

Referring now to FIGS. 7 and 8, FIG. 7 shows an example flow of datathrough platform hub 320 and FIG. 8 is a flow chart describing the stepsof the data flow. The example data flow begins in step 801, wherein thecommunication agent 110 c(1) receives a data payload to be delivered toprocessing agent 110 b(1). For example, communication agent 110 c(1) mayreceive a TCP/IP packet from a network and this TCP/IP packet may needto be delivered to processing agent 110 b(1) so that the packet can beprocessed.

In step 802, the adapter that serves agent 110 c(1) (i.e., adapter 310c(1)) receives the payload from agent 110 c. In step 804, the adapterparses the data payload (e.g., the adapter examines the header of theTCP/IP packet) to determine the stream or connection to which the packetbelongs (in this example, we shall assume the packet belongs to streamN). One objective of adapter 310 c may be to perform such classificationoperation in a persistent manner, hence sending packets of the samelogical and operational characteristics (need similar operations to beperformed upon them) to the same processing agent 110 b.

In step 805, the adapter retrieves and/or generates certainclassification information in response to determining that the packetbelongs to stream number N. That is, the classification information thatis generated/received depends, at least in part, on the fact that thepacket belongs to stream N.

In step 806, the adapter performs the following steps: (1) creates adirective that includes all the relevant data that was gathered/createdin step 805, if any, along with a list of instructions to be performedon the data payload, (2) adds the directive to the head of the datapayload, thereby creating a data container, and (3) passes the datacontainer to interconnect 330. FIG. 9 illustrates an example directivethat may be created in step 806. The example directive includes two moveinstructions 901 and 902 and an extra information record 903.

In step 807, interconnect 330 receives the data container from adapter310 c(1) and removes instruction 901 from the directive and routes thedata container to the port identified in move command 901 (i.e., port#3), which is the port to which the adapter for processing agent 110b(1) is attached.

In step 808, adapter 310 b(1) receives the data container frominterconnect 330, pops the second move instruction (i.e., instruction902) from the directive, which instruction indicates the ultimatedestination for the data payload (i.e., host memory #1 in this example).

In step 810, the adapter 310 b(1) causes the data payload to be storedin host memory #1 and also causes at least some of the informationcontained in record 903 to be stored in a predefined descriptor storagearea, which may be in host memory #1.

Referring now to FIGS. 10 and 11, FIG. 10 shows an exampleimplementation of the data flow shown in FIG. 7 and FIG. 11 is a flowchart describing the steps of the example implementation.

The data flow begins in step 1102, wherein the communication agent 110c(1) receives a data payload to be delivered to processing agent 110b(1). For example, communication agent 110 c(1) may receive a TCP/IPpacket from a network and this TCP/IP packet may need to be delivered toprocessing agent 110 b(1) so that the packet can be processed.

In step 1104, the interface (e.g. an Ethernet Mac interface) receivesthe payload from agent 110 c and translates the information from 1^(st)layers.

In step 1106, the payload is passed to the DMA 613, which in this simplescenario doesn't need to perform any batch operation (in a morecomplicated example it could decide for instance to perform a back-upwrite operation to a storage device while passing the data to theclassifier), and DMA 613 passes the data payload to classifier 612.

In step 1108, the classifier 612 parses the data payload to determinethe stream or connection to which the packet belongs (in this example,we shall assume the packet belongs to stream number N).

In step 1110, the classifier 612 retrieves and/or generates certainclassification information based, at least in part, on the fact that thepacket belongs to stream number N. It then passes, out-of-band, to AE611 the classification information and also passes the data payload toAE 611.

In step 1112, AE 611 receives the classification information, creates adirective that includes all the relevant data that was gathered throughout the classification phase along with a list of instructions to beperformed on the data payload, adds the directive to the head of thedata payload, thereby creating a data container, and passes the datacontainer to interconnect 330.

In step 1114, interconnect 330 removes instruction 901 from thedirective and routes the data container to the port identified in movecommand 901 (i.e., port #3), which is the port to which the adapter forhost 202 is attached.

In step 1116, classifier 601 receives the data container frominterconnect 330, pops the second move instruction (i.e., instruction902) from the directive, which instruction indicates the ultimatedestination for the data payload (i.e., host memory #1 in this example),passes the data container to AE 602, and passes, out-of-band, to the AE602 a command to send the data payload to the memory identified in themove instruction (i.e., host memory #1).

In step 1118, AE 602 pops record 903 and passes, out-of-band, to the DMA603 the extra information contained therein. In step 1120, DMA 603performs a store request to host memory #1 of all packet data. The extrainformation is sent to a predefined descriptor area also in host memory#1. In step 1122, interface 604 translates the request to the hostspecific bus. In step 1124, data payload is stored in host memory #1.

The scalable structure of platform hub 320 enables fast, efficient andscalable control over the system platform agents. By using the directivestructure, control signals in the system can be passed as in-bandmessages (in fact, signals can be even sent as piggy-backed informationupon existing traffic in the opposite direction). An example of acontrol messages is an instruction from host 202 to one or moreclassifiers 612 to watch out for a new virus. In such scenario, host 202sends a message to some or all adapters 310, in a request to updatetheir tables according to the new classification scheme. Host 202 canupdate the adapters 310 by performing a memory-mapped-io-write to theadapters or by sending a control packet with a predefined packet format.

SECOND EXAMPLE

Referring now to FIGS. 12 and 13, FIG. 12 shows another example flow ofdata through platform hub 320 and FIG. 13 is a flow chart describing thesteps of data flow.

Referring to FIG. 13, in step 1302, host 202 outputs data (1), whichdata is received by adapter 310 b(1). In this example, the data includesan adapter configuration command or “management packet” that should besent to other adapters (e.g., adapters 310 a,c,d.

In step 1304, adapter 310 b(1) examines the received data and determinesthat it includes an adapter configuration command. Because the dataincludes an adapter configuration command, adapter 310 b(1) creates acertain directive (2) and provides the directive to interconnect 330(step 1306). In some embodiments, the directive is provided tointerconnect 330 by piggybacking on existing packet streams. That is, insome embodiments, the directive is added to a data payload to create adata container, and the data container is sent to interconnect 330.

FIG. 14 illustrates an example directive that may be created in step1304. As illustrated in FIG. 14, the directive created in step 1304 mayinclude two instructions: (1) an instruction for the interconnect 330(instruction 1401, which in this example is a MOVE instruction) and (2)another instruction for the other adapters (instruction 1402).

In step 1308, interconnect 330 receives the directive, removes (pops)the MOVE instruction from the directive, which move instructioninstructs interconnect 330 to provide the remaining instruction to ports1, 2 and 4, and then provides the remaining instruction to eachidentified port so that it is received by the adapters connected tothose ports.

In step 1310, the adapters connected to ports 1, 2 and 4 (i.e., adapters310 a, 310 c(1) and 310 d in this example) receive the instruction 1402from the interconnect and update their configuration information (e.g.,configuration tables) accordingly. In this example, the instructiontells the adapters to drop a packet if the packet meets a certaincriteria specified in instruction 1402.

In step 1312, a new packet 3 that meets the specified criteria isreceived at the communication agent 110 c(1), which outputs the packetsuch that it is received by adapter 310 c(1). When this packet reachesadapter 310 c(1), the packet and the adapter's configuration informationare examined by the adapter to determine whether the adapter needs totake any action with respect to the packet (step 1314). Because, in thisexample, the packet meets the criteria specified in instruction 1402(e.g., the packet is a malicious packet), the adapter performs theaction specified in instruction 1402 (i.e., the adapter drops thepacket) (step 1316).

Referring now to FIGS. 15 and 16, FIG. 15 shows an exampleimplementation of the data flow shown in FIG. 12 and FIG. 16 is a flowchart describing the steps of the example implementation.

In step 1601, host 202 performs a write to the platform hub 320. In step1602, the agent interface connected to host 202 translates the registerwrite into a predefined-format (e.g., a fixed-length packet) andprovides the packet to the DMA to which it is connected. In step 1603,the DMA passes the packet to the classifier to which the DMA isconnected.

In step 1604, the classifier examines the packet and identifies that thepacket as a “management packet”. The classifier then issues a request tothe AE to create a certain directive and provide the directive tointerconnect 330. In step 1605, the AE creates the required directiveand provides it to interconnect 330.

In step 1606, interconnect 330 receives the directive, removes (pops)the MOVE instruction from the directive, which move instructioninstructs interconnect 330 to provide the remaining instruction to ports1, 2 and 4, and then provides the remaining instruction to eachidentified port so that it is received by classifier 601 in each of theother three adapters.

In step 1607, each classifier 601 in the other adapters receives theinstruction 1202 from the interconnect and identifies that theinstruction should be sent to its neighboring classifier 612. Eachclassifier 601 then passes the instruction to its neighboring classifier612. In step 1608, each classifier 612 receives instruction 1402 andupdates its tables accordingly. In this example, the instruction tellsclassifier 612 to drop a packet if the packet meets a certain criteriaspecified in instruction 1402.

In step 1609, a new packet that meets the specified criteria is receivedat the communication channel. When this packet reaches the classifier612 of adapter 310 c(1), the packet is examined by the classifier andthe classifier issues a drop command to the AE because the packet meetsthe specified criteria (i.e., it is a malicious packet) (step 1610). TheAE then drops the malicious packet (step 1611).

THIRD EXAMPLE

Referring now to FIGS. 17 and 18, FIG. 17 show another example flow ofdata through platform hub 320 and FIG. 18 is a flow chart describing thesteps of the data flow.

Referring now to FIG. 18, the data flow may begin in step 1801, whereincommunication agent 110 c(1) receives a protocol packet to be deliveredto processing agent 110 b(1). In step 1802, adapter 310 c(1) receivesthe packet from communication agent 110 c(1).

In step 1803, adapter 310 c(1) parses the protocol packet and determinesthe stream to which the packet belongs (e.g., it may identify that thepacket as belonging to a certain stream (e.g., stream #N)) anddetermines, based on the determined stream, whether the protocol packetshould be “split.” A split operation means that, for example, certaindata and/or only a portion of the packet (e.g., the first X number ofbytes of the packet, where X is greater than or equal to 0) need beprovided to processing agent 110 b(1), while a copy of the entire packetshould be copied to storage agent 110 d (which may be referred to as“platform memory”). For this example, we shall assume the packet shouldbe split.

In step 1804, the adapter builds a vector of fields. This field-vectormay include: fields that were extracted from the packet header (e.g.,source/destination addresses Ethernet/IP etc.), fields extracted fromthe packet application data, data resulting from a certain operation(e.g. tupliz-hash calculation on the packet data/header-fields) and/ordata retrieved from storage (e.g., from stored configurationinformation).

In step 1805, adapter 310 c(1) creates a first data container thatincludes a data payload and a directive. The data payload includes thefirst X bytes of the protocol packet (X >=0). The directive includes:(1) routing information that instructs interconnect 330 to provide thedata container to adapter 310 b, (2) the field-vector and (3) a uniqueidentifier that represents the protocol packet and is used, in a laterphase, to retrieve the protocol packet. This data container is then sentto the processing agent 110 b(1).

In step 1806, adapter 310 c(1) creates a second data container thatincludes a data payload and a directive. The data payload includes theentire application data portion of the protocol packet (it may alsoinclude the headers). The directive includes: (1) routing informationthat instructs interconnect to provide the data container to adapter 310d and (2) the unique identifier.

In step 1807, the interconnect directs each of the two data containersto the appropriate adapters based on the routing information.

In step 1809(a), at least a portion of the second data container isreceived by adapter 310 d, which then determines the location (e.g.,ring) in the platform-memory into which the packet should be inserted.In step 1810(a), adapter 310 d performs all the necessary memory writesto insert the data payload into the appropriate memory location ofstorage 110 d.

In step 1809(b), at least a portion of the first data container isreceived by adapter 310 b(1).

In step 1810(b), the adapter 310 b(1) causes the data (i.e., the first Xbytes of the protocol packet, the field-vector and unique identifier) tobe stored in host memory #1.

Using at least some of the data received from adapter 310 b(1), anapplication running on the host determines that the protocol packetshould be routed to the communication agent 110 c(1) with a differentdestination address. The application does not necessarily know it holdsonly a part of the packet. Accordingly, the application sends the Xbytes packet as if it was the entire packet. In step 1811, the host 202passes the X bytes of the packet to the adapter 310 b(1) along with theunique identifier.

In step 1812, the adapter 310 b(1) identifies that this packet is a“split” packet based on information received from the host and creates adirective. The directive includes: (1) a first MOVE instruction 1901(see FIG. 19) that identifiers adapter 310 c(1) as the destination ofthe directive, (2) a merge instruction 1902 and (3) a second MOVEinstruction 1903 that identifiers adapter 310 d as the destination ofthe directive. The adapter then passes the directive to theinterconnect.

In step 1813, the interconnect removes and executes the second (i.e.,top) MOVE command 1903, thereby sending the directive to adapter 310 d.

In step 1814, adapter 310 d receives the directive from theinterconnect, removes from the received directive the merge instruction1902 and looks up the unique identifier (e.g., look the identifier up ina memory ring mapping table). The adapter 310 d then obtains the packetfrom the memory agent 110 d using the unique identifier.

In step 1815, adapter 310 d updates the header of the packet accordingto the merge instruction and attaches to the packet move instruction1901. The data container is then provided to the interconnect 330.

In step 1816, the interconnect 330 pops the MOVE instruction containedin the directive of the data container and directs the data payload ofthe data container (i.e., the protocol packet) to adapter identified inthe MOVE instruction (which, in this case is adapter 310 c(1)).

In step 1817, the adapter 310 c(1) provides the protocol packet to thecommunication agent 110 c(1), which may then transmit the packet over acommunication channel.

As illustrated by the above example, the capabilities of PH 320 canimprove performance of device 100 by preventing unnecessary data fromgetting to the host memory. As illustrated above, the host can perform arouting decision for a packet without needing the entire packet. Forexample, the host needs only a finite set of fields upon which it routesthe packet. Since the uplink to the host (and from the host to it'smemory) is a bottleneck in the system, saving data transfers on this buscan improve the entire platform performance.

Referring now to FIGS. 20A,B and 21A,B, FIGS. 20A,B show an exampleimplementation of the data flow shown in FIG. 17 and FIGS. 21A,B is aflow chart describing the steps of the example implementation.

Referring now to FIG. 21A, the data flow may begin in step 2101, whereincommunication agent 110 c(1) receives a protocol packet to be deliveredto processing agent 110 b(1). In step 2102, the interface (e.g. EthernetMac) translates the information from 1^(st) and/or 2^(nd) layers. Instep 2103, the packet is passed to the DMA module, which in a simplecase scenario doesn't need to perform any batch operation and simplypasses the packet to the classifier.

In step 2104, classifier parses the protocol packet and determines thestream to which the packet belongs (e.g., it may identify that thepacket as belonging to a certain stream (e.g., stream #N)) anddetermines, based on the determined stream, whether the protocol packetshould be “split.” A split operation means that, for example, certaindata and/or only a portion (e.g., the first X number of bytes of thepacket, where X is greater than or equal to 0, along with fields thatwere gathered by the classifier/parser and inserted as directives ofextra-info to the processor) need be provided to processing agent 110b(1), while a copy of the entire packet or the portion of the packetthat was not sent to the processing agent should be copied to storageagent 110 d (which may be referred to as “platform memory”). For thisexample, we shall assume the packet should be split.

In step 2105, the classifier builds a vector of fields. Thisfield-vector may include fields that were extracted from the packetheader (e.g., source/dest addresses eth/ip etc.), fields extracted fromthe packet data, and/or data resulting from a certain operation (e.g.tupliz-hash calculation on the packet data/header-fields) or retrievedfrom storage (e.g., from stored configuration information).

In step 2106, the classifier sends a “split” command to the actionengine along with the entire protocol packet and the field-vector.

In step 2107, the action engine creates a first data container thatincludes a data payload and a directive. The data payload includes thefirst X bytes of the protocol packet. The directive includes: (1)routing information that instructs interconnect 330 to provide the datacontainer to adapter 310 b(1), (2) the field-vector and (3) a uniqueidentifier that represents the protocol packet and is used, in a laterphase, to retrieve the protocol packet.

In step 2108, the action engine creates a second data container thatincludes a data payload and a directive. The data payload includes theentire application data portion of the protocol packet (it may alsoinclude the headers). The directive includes: (1) routing informationthat instructs interconnect to provide the data container to adapter 310d and (2) the unique identifier.

In step 2109, the interconnect directs each of the two data containersto the appropriate adapters 310 based on the routing information.

In step 2110(a), at least a portion of the second data container isreceived by the TX classifier of adapter 310 d, which then determinesthe location (e.g., ring) in the platform-memory into which the packetshould be inserted and provides the location information and the datapayload to the action engine.

In step 2111(a), the action engine passes the data payload to the DMAalong with the location information determined by the classifier.

In step 2112(a), the DMA receives the data payload and the locationinformation, and performs all the necessary memory writes through theinterface (which may resemble a Memory Controller) to insert the datapayload into the appropriate memory location.

In step 2110(b), at least a portion of the first data container isreceived by the TX classifier of adapter 310 b and the classifier passesa command to the action engine to send the data received by theclassifier to Host memory #1.

In step 2111(b), the action engine removes from the directive thefield-vector and passes it (e.g., out-of-band) and the data payload tothe DMA.

In step 2112(b), the DMA provides to the agent interface a request tostore the data payload the field-vector, and unique identifier in hostmemory #1. The field-vector is sent to a predefined descriptor area inHost memory #1.

In step 2113 (see FIG. 21B), the agent interface translates the requestto the host specific bus. In step 2114, the data (i.e., the first Xbytes of the protocol packet, the field-vector and unique identifier) isstored in host memory #1.

Using the field-vector it received and the first X bytes from theprotocol packet, an application running on the host determines that theprotocol packet should be routed to the communication agent 110 c(1)with a different destination address. The application does notnecessarily know it holds only a part of the packet. Accordingly, itsends the X bytes packet as if it was the entire packet.

In step 2115, the host passes the X bytes of the packet to the DMAthrough the agent interface along with a descriptor that includes theunique identifier.

In step 2116, the agent interface passes the packet and it's descriptorto the DMA which passes the information to the classifier.

In step 2117, the classifier identifies that this packet is a “split”packet based on information received from the host and then passes a“merge” command to the action engine. The merge command includes: anidentifier identifying adapter 310 d, an identifier identifying adapter310 c(1), and the unique identifier.

In step 2118, the action engine creates a directive. The directiveincludes: (1) a first MOVE instruction that identifiers adapter 310 c(1)as the destination of the directive, (2) a merge instruction and (3) asecond MOVE instruction that identifiers adapter 310 d as thedestination of the directive. The action engine then passes thedirective to the interconnect.

In step 2119, the interconnect removes and executes the second (i.e.,top) MOVE command, thereby sending the directive to adaptor 310 d.

In step 2120, the TX classifier of adapter 310 d receives the directivefrom the interconnect, removes from the received directive the mergeinstruction and looks up the unique identifier (e.g., look theidentifier up in a memory ring mapping table). The classifier theninstructs the DMA to obtain the packet from the memory agent 110 d.

In step 2121, the TX classifier also provides a merge request to the RXclassifier with the unique identifier that was extracted from the mergeinstruction and provides the directive to the RX classifier, which nowonly includes the first MOVE instruction. The RX classifier awaits thefull packet to return from the DMA.

In step 2122, the DMA issues a set of read operations in order toreceive the packet from the memory agent 110 d.

In step 2123, the DMA passes the full packet along with its uniqueidentifier to the RX classifier.

In step 2124, the RX classifier passes to the action engine: (1) thedirective it received from the TX classifier (2) a packet updatecommand, and (3) the full packet. The packet update command includes thefields (e.g., IP and/or Ethernet destination address) that should bereplaced and their new values.

In step 2125, the action engine updates the header of the full packetaccording to the update command it received from the classifier andattaches to the packet the directive it received, thereby creating adata container. The data container is then provided to the interconnect.

In step 2126, the interconnect pops the MOVE instruction contained inthe directive of the data container and directs the data payload of thedata container (i.e., the protocol packet) to adapter identified in theMOVE instruction (which, in this case is adapter 310 c(1)).

In step 2127, the adapter 310 c(1) provides the protocol packet to thecommunication agent 110 c(1), which may then transmit the packet over acommunication channel.

Referring now to FIG. 23, FIG. 23 illustrates a system 2300 according tosome embodiments of the invention. As illustrated in FIG. 23, the abovedescribed features of the present invention can be used to enable thecreation of a scalable multi-node interconnect network 2300. In system2300, a platform hub 320 and its associated agents are considered to bea “node.” In the example shown in FIG. 23, system 2300 includes twonodes (i.e., node #1 and node #2) that interconnect with each otherusing scalability adapter units 2302.

While FIG. 23 illustrates the scalability adapter unit of node #1 beingconnected to the scalability adapter unit of node #2, this was donemerely for illustration. It is contemplated that an interconnect may bepositioned between the scalability adapter units, thereby enabling ascalability adapter unit to communicate with several other scalabilityadapter units.

There can be several ways to implement a multi-node network, such asnetwork 2300. An example of a simple implementation would be to add anode identifier to a MOVE instruction. In addition, in this kind ofimplementation, DMA translation tables may have to be enlarged toinclude its visible ports in each node. Each interconnect 330 may hold astructure that indicates the correct scalability CAU 2302 to which tosend each packet in order to get to the required node. Each interconnectrouting structure is configured to forward each packet to the correctnode. A packet that reaches its destination node is routed by theinterconnect of the destination node to the correct port on that node.In some embodiments, an interconnect 330 pops the head MOVE command onlyif the node identifier included in the MOVE command identifies the nodeof the interconnect.

The scalability CAUs 2302 enable the connection between the differentinterconnects, thereby connecting different nodes. The scalability CAUcan be configured to forward multicast messages to the next node orrestrict them to the nodes boundary.

Each communication CAU (i.e., a CAU that serves a communication agent)can be further configured to enable a fail-proof structure. In case of afail or high-load situation on the nodes processing agents, acommunication CAU may forward new incoming streams to a different node.This feature is illustrated in FIG. 24. As illustrated in FIG. 24, CAU310 c(1) of node #2 may receive a data from agent 110 c(2) of node #2and, instead of sending the data to a processing agent of node #2, maysend the data to a processing agent on node #1 by, for example, creatinga data container that contains the data and a directive that includes aMOVE command that includes an identifier identifying node #1, which movecommand causes the interconnect 330 of node #2 to send the datacontainer to the scalability unit 2302 of node #2. Upon receiving thedata container, the scalability unit 2302 of node #2 sends the datacontainer to an adapter unit of node #1. This adapter unit of node #1may send the data to a processing agent on node #1, which processingagent may process the data and then send the processed data to acommunication agent on node #1. In this manner, a communication streamfrom one node is directed to a processing agent in another node and thenforwarded to a different communication agent.

Using several platform hubs in a scalable connection enables multipleconnections to several processors and gives the ability to spreadtraffic from a single communication agent to a scalable number ofprocessing agents. This feature is illustrated in FIG. 25. Asillustrated in FIG. 25, CAU 310 c(1) may be configured so that some datareceived from agent 110 c(1) is provided to a processing agent of node#2, whereas some other data received from agent 110 c(1) is provided toa processing agent of node #1. For example, CAU 310 c(1) may beconfigured so that protocol packets received from agent 110 c(1) havinga certain characteristic (e.g., source address or other characteristic)are provided to a processing agent on node #1, whereas other protocolpackets are provided to a processing agent of node #2. In this manner,traffic can be spread to a scalable number of processing agents.

Additionally, using several platform hubs in a scalable connectionenables multiple connections to a communication agent. This means thecommunication channel bandwidth is scalable as well. This feature isillustrated in FIG. 26.

While various embodiments/variations of the present invention have beendescribed above, it should be understood that they have been presentedby way of example only, and not limitation. Thus, the breadth and scopeof the present invention should not be limited by any of theabove-described exemplary embodiments.

Additionally, while the processes described above and illustrated in thedrawings are shown as a sequence of steps, this was done solely for thesake of illustration. Accordingly, it is contemplated that some stepsmay be added, some steps may be omitted, and the order of the steps maybe re-arranged.

What is claimed is:
 1. A processing device, comprising: a housing; achip housed in the housing; a first processing agent housed in thehousing and connected to the chip; and a network interface operable toconnect the processing device to an external network that is external tothe housing, wherein the chip comprises: an interconnect; a secondprocessing agent communicatively connected to the interconnect, thesecond processing agent comprising a plurality of general purposeprocessor cores and a cache memory; and a network adaptercommunicatively connected to the interconnect and to the networkinterface, the network adapter being operable to receive and classifypackets received from the network interface, wherein the network adapteris configured such that, in response to receiving a particular packet,the network adapter uses the interconnect to store a payload portion ofthe packet in the cache memory of the second processing agent.
 2. Theprocessing device of claim 1, wherein the network adapter is configuredsuch that, in response to receiving via the network interface a packethaving a header and a data payload, the network adapter i) compares datafrom both the data payload and header with pre-determined data, and ii)performs a certain predetermined action in response to determining thatthe compared data matches the predetermined data.
 3. The processingdevice of claim 2, wherein the network adapter comprises a packet parserand an action engine communicatively connected to the packet parser,wherein the action engine is operable to receive from the packet parserpacket data and/or commands, and the action engine is further operableto do one or more of (i) perform a packet filtering operation on packetsparsed by the packet parser and (ii) perform a packet modificationoperation on packets parsed by the packet parser.
 4. The processingdevice of claim 1, wherein the chip further comprises an acceleratingagent communicatively connected to the interconnect, the acceleratingagent being adapted to perform acceleration operations.
 5. Theprocessing device of claim 4, wherein the accelerating agent is acryptographic accelerating agent, and the second processing agent isadapted to use the interconnect to provide to the cryptographicaccelerating agent i) the payload and ii) a command identifying acryptographic operation that the cryptographic accelerating agent shouldperform on the payload.
 6. The processing device of claim 5, wherein thecryptographic accelerating agent comprises a direct memory access (DMA)engine coupled to the interconnect, and the DMA engine is configured toi) receive the payload provided by the second processing agent and ii)write the payload into a memory space of the cryptographic agent.
 7. Achip for use in a network server comprising a first processing agent anda network interface, said chip comprising: an interconnect; a secondprocessing agent communicatively connected to the interconnect, thesecond processing agent comprising a plurality of general purposeprocessor cores and a cache memory; a network adapter communicativelyconnected to the interconnect and to the network interface, the networkadapter being operable to receive and classify packets received from thenetwork interface; and an accelerating agent communicatively connectedto the interconnect, the accelerating agent being adapted to performacceleration operations.
 8. The chip of claim 7, wherein the networkadapter is configured such that, in response to receiving via thenetwork interface a packet having a header and a data payload, thenetwork adapter i) compares data from both the data payload and headerwith pre-determined data, and ii) performs a certain predeterminedaction in response to determining that the compared data matches thepredetermined data.
 9. The chip of claim 8, wherein the network adaptercomprises a packet parser and an action engine communicatively connectedto the packet parser, wherein the action engine is operable to receivefrom the packet parser packet data and/or commands, and the actionengine is further operable to do one or more of (i) perform a packetfiltering operation on packets parsed by the packet parser and (ii)perform a packet modification operation on packets parsed by the packetparser.
 10. The chip of claim 7, wherein the network adapter comprises apacket parser, an action engine, and an identifier module operable toreceive packet information from the packet parser and, based on thepacket information and configuration data, provide a command to theaction engine.
 11. The chip of claim 7, wherein the network adapter isoperable to determine a flow to which a packet received from the networkinterface.
 12. The chip of claim 11, wherein the network adapter isoperable to determine whether a received packet meets specified criteriaand is operable to drop the received packet in response to determiningthat the packet meets the specified criteria.
 13. The chip of claim 11,wherein acceleration agent is a cryptographic acceleration agent. 14.The chip of claim 7, wherein the network adapter is further operable,such that, in response to receiving a packet from the network interface,the network adapter is operable to determine whether the received packetcomprise a Transmission Control Protocol (TCP) protocol data unit (PDU).15. A chip for use in a processing device, said chip comprising: aninterconnect; a first processor communicatively connected to theinterconnect and communicatively connected to a network interface, thefirst processor being operable to receive packets via the networkinterface; and a second processor communicatively connected to theinterconnect, the second processor comprising a plurality of processorcores and cache memory, wherein the first processor is configured to:parse a packet received via the network interface and perform one ormore actions based on information contained in the received packet,wherein said actions include providing at least a portion of thereceived packet to the cache memory of the second processor via theinterconnect.
 16. The chip of claim 15, wherein the cache memorycomprises a plurality of L2 caches.
 17. The chip of claim 15, whereinthe first processor comprises: a packet parser configured to parsepackets provided to the first processor from a communication agent andto extract one or more fields from the packets; and a configurableaction engine operable to (a) receive one or more packet fieldsextracted by the packet parser and (b) perform one or more actions basedon information contained in the received one or more packet fields,wherein said actions include providing a received packet to the secondprocessor via the interconnect.
 18. The chip of claim 17, wherein theaction engine is operable to perform packet filtering of the packetsreceived from the communication agent.
 19. The chip of claim 15, furthercomprising: an accelerating agent configured to perform a cryptographicfunction, the accelerating agent being communicatively connected to thesecond processor through the interconnect.
 20. The chip of claim 15,wherein the first processor is operable to determine whether a packetreceived via the network interface meets specified criteria and isoperable to drop the packet in response to determining that the packetmeets the specified criteria.